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EXECUTIVE  SUMMARY 

* 

k 

a.  Part  of  our  College  mission  is  distribution  of  the 
students’  problem  solving  products  to  DoD 
rt,  sponsors  and  other  interested  agencies  to 
enhance  insight  into  contemporary,  defense 
2^  related  issues.  While  the  College  has  accepted  this 
product  as  meeting  academic  requirements  for 
?  graduation,  the  views  and  opinions  expressed  or 
implied  are  solely  those  of  the  author  and  should 
not  be  construed  as  carrying  official  sanction. 


“insights  into  tomorrow * 


REPORT  NUMBER  84-2605 

AUTHOR(S)  MAJOR  JAMES  P.  TOTSGH,  USAF 

TITLE  IMPLEMENTING  AUTOMATED  INFORMATION  SYSTEMS  IN  THE  AIR 
FORCE 

I.  Purpose!  3To  review  and  evaluate  Air  Force  guidance  on  imple¬ 
menting  information  systems  and  to  provide  step-by-step  procedures 
on  how  to  implement  such  systems, 

II .  Problems  The  rapidly  changing  technology  in  the  computer 
hardware  and  software  areas,  as  well  as  advances  in  electronic 
communications,  has  spawned  a  merging  of  disciplines  into  what  is 
known  today  as  information  systems.  The  Congressional  passage 
of  Public  Law  96-511, or  the  Paperwork  Reduction  Act  of  1980  has 
caused  Federal  agencies  to  start  viewing  information  as  a  resource 
and  to  develop  information  resources  management  (IRM)  policy. 
Developing  this  policy  requires  a  new  perspective  on  the  Air  Force’s 
approach  to  management  and  control  of  word  processing  equipment, 
computers,  and  telecommunications  equipment. 

III.  Data 1  The  Air  Staff  formed  the  new  Assistant  Chief  of  Staff 
for  Information  Sytems  on  1  June  1983.  That  agency  is  struggling 
with  the  problem  of  developing  IRM  guidance  for  the  Air  Force. 

The  Air  Force  has  several  agencies  and  individuals  who  have  imple¬ 
mented  information  systems  in  recent  years.  They  understand  the 
difficulties  involved  in  implementing  a  system  so  diverse  that  it 
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CONTINUED 


crosses  several  functional  lines.  Using  the  experiences  of  these 
individuals  and  those  of  civilian  managers  who  have  done  similar 
work  within  their  industries,  the  Air  Staff  can  develop  guidance 
and  step-by-step  procedures  that  lead  a  user  through  the  planning, 
organizing,  developing,  and  controlling  of  information  systems. 

IV.  Conclusions!  The  Air  Force  is  having  difficulty  converting  the 
controls  they  had  over  mainframe  computers  into  a  manageable  approach 
for  handling  the  micro-technology  and  networking  involved  in  the 
information  environment  today.  The  Air  Staff  is  struggling  with 

the  difficult  problem  of  releasing  the  controls  on  these  systems 
without  opening  the  flood  gates.  Lessons  within  industry  show 
that  many  companies  have  addressed  this  problem  through  an  evolu¬ 
tionary,  phased  development  approach. 

V.  Recommendations i  The  new  Air  Staff  organization  must  exert 
creative  leadership so  the  rest  of  the  Air  Force  can  benefit  from 
this  new  technology  and  information  systems  approach.  They  must 
loosen  the  reigns  on  previous  controls  that  were  very  well  required. 
However,  the  micro-technology  of  today  and  the  electronic  network¬ 
ing  available  make  these  controls  outdated.  New  guidance  must 
identify  the  steps  involved  in  managing  the  new  technology,  but  not 
be  so  restrictive  that  the  technology  is  obsolete  before  it  can 

be  installed. 
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Chapter  One 


INTRODUCTION 


BACKGROUND  OF  THE  PROBLEM 

The  last  two  decades  have  brought  dynamic  changes  in  the  way 
we  collect*  use,  and  disseminate  information.  During  that  time, 
we  have  seen  the  growth  of  the  use  of  computers  into  almost  all 
facets  of  our  business  lives.  We  have  seen  an  evolution  of  the 
computer  environment  from  large  circuitry  to  micro-technology. 

This  evolution  caused  Booz,  Allen  it  Hamilton,  Inc.,  to  compare 
the  information  resources  environment  in  the  1960's  and  the  1980's. 
They  characterized  the  early  1960's  environment  as  followsi 

-  Highly  centralized  processing  power 

-  Systems  costs  dominated  by  hardware  costs 

-  Low  power  languages/user  skill  requirements  high 

-  Highly  centralized  operation  and  data  management 

-  System  design  strategyi  maximize  machine  efficiency 

-  Management  control  strategyi  interdict  the  purchase 
of  mainframe  computers  (1«5) 

Booz,  Allen  &  Hamilton,  Inc.,  contrasted  the  1960's  environ¬ 
ment  with  the  1980's  by  describing  the  1980's  as  followsi 

-  Distributed  processing  power 

-  Hardware  costs  rapidly  decliningi  systems  costs 
soon  to  be  dominated  by  software  costs 

-  Higher  order  languages/user  skill  requirements  low 

-  Distributed  ownership,  operation,  and  data  manage¬ 
ment 

-  System  design  strategyi  strike  a  new  balance  between 
machine  efficiency  and  system  effectiveness 

-  Management  control  strategyi  control  the  growth  of 
the  full  range  of  information  resources  (I16) 

This  comparison  shows  that  the  advances  of  technology  over 
the  past  20  years  have  caused  managers  to  change  their  philosophy 
and  approach  when  looking  at  the  resources  used  to  manipulate 
information.  The  96th  Congress  of  the  United  States  recognized 
the  change  and  enacted  Public  Law  96-511,  commonly  referred  to  as 
the  Paperwork  Reduction  Act  of  1980.  This  Act  includes  many 
statutes,  but  the  main  thrust  is  that  it  directs  Federal  agencies 
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to  view  information  as  a  resource  just  as  they  view  money, 
materiel,  and  manpower  (4*2812-2815).  Thus,  the  Act  has 
spawned  a  term  that  has  become  common  throughout  the  Federal 
Governments  information  resources  management  (IRM).  IRM  was 
defined  by  the  National  Bureau  of  Standards  Panel  on  Standards 
and  Controls  for  IRM  meeting  in  October  I98I  as 

whatever  policy,  action,  or  procedure  concerning  infor¬ 
mation  (both  automated  or  non-automated)  which  manage¬ 
ment  establishes  that  serves  the  overall  current  and 
future  needs  of  the  enterprise.  Such  policies,  etc., 
would  include  considerations  of  availability,  timeli¬ 
ness,  accuracy,  integrity,  privacy,  security,  audita¬ 
bility,  ownership,  use  and  cost-effectiveness  (2*2-11  - 
2-12). 

Viewing  information  as  a  resource  has  caused  Federal  agencies 
to  reassess  the  way  they  have  managed  information  in  the  past. 

For  the  Air  Force,  this  has  meant  reassessing  the  way  it  has 
handled  information  under  three  very  distinct  disciplines  -  auto- 
matic  data  processing,  telecommunications,  and  administration. 

The  reassessment  resulted  in  a  merging  of  disciplines  at  the  Ai: 
Staff  when,  on  1  June  1983,  the  new  Assistant  Chief  of  Staff  fo 
Information  Systems  was  formed.  This  organization  is  "response  i 
to  the  Chief  of  Staff  of  the  Air  Force  for  providing  USAF  polic,  , 
guidance,  planning,  programming,  budgeting,  and  oversight  for  in 
formation  systems"  (5»Attachment  2).  They  have  written  a  new 
regulation.  Air  Force  Regulation  ?00-l,  entitled  Managing  Air 
Force  Information  Systems,  which  "establishes  policy,  objectives, 
and  responsibilities  for  managing  Air  Force  Information  Systems" 
(3:D. 


OBJECTIVES  OF  THIS  STUDY 

In  this  paper,  the  author  will  review  the  way  in  which  the  Air 
Force  plans  to  implement  information  systems.  He  will  use  his  own 
experiences  in  implementing  an  information  system  at  the  Air  Staff 
and  by  assisting  with  the  initial  actions  to  develop  a  similar 
system  at  the  Air  Command  and  Staff  College  (ACSC)  to  outline  the 
steps  one  must  follow  to  implement  an  information  system  in  the 
Air  Force.  He  will  then  conclude  by  evaluating  the  adequacy  and 
applicability  of  current  guidance.  Thus,  the  paper  will  not  only 
provide  feedback  to  the  Air  Staff  on  the  appropriateness  of  their 
IRM  guidance,  but  it  will  also  help  others  trying  to  implement 
an  automated  information  system  in  preparing  for  some  of  the 
challenges  ahead  of  them. 


ORGANIZATION  OF  THE  STUDY 


The  paper  will  explain  the  step-by-step  procedures  to  follow 
in  implementing  an  information  system.  The  first  step  will  ex- 


plain  how  an  organization  gets  started.  This  includes  assignment 
of  responsibility  and  the  steps  the  office  of  primary  responsi¬ 
bility  must  follow  to  garner  support.  The  second  step  is  to  ex¬ 
plain  how  requirements  are  determined  and  documented  to  use  in 
developing  the  information  system  plan  -  the  third  step  in  the 
process.  The  fourth  step  will  describe  how  the  plan  should  be 
implemented  and  how  feedback  should  be  obtained.  Finally,  the 
paper  will  evaluate  current  Air  Force  guidance  and  procedures 
and  recommend  appropriate  changes  to  this  guidance  to  meet  the 
future  challenges  in  implementing  automated  information  systems. 


Chapter  Two 


GETTING  STARTED 

WHO'S  IN  CHARGE? 


The  first  problem  that  confronts  an  organization  that  takes 
on  the  task  of  implementing  an  automated  information  system  is 
to  decide  who  should  be  the  implementer.  The  natural  tendency 
is  to  find  someone  who  is  technically  trained  -  a  data  automator, 
telecommunicator,  or  administrator  -  and  put  them  in  charge. 

Many  times  that  is  a  mistake!  What  is  needed  is  an  individual 
who  can  bridge  the  gap  between  the  future  user  of  the  system 
and  the  technocrat  who  is  going  to  help  get  it.  The  technically 
trained  sometimes  have  difficulty  communicating  with  the  user. 

Communications  had  ground  to  a  halt  between  the  data  pro¬ 
cessing  (DP)  department  and  the  outside  world.  In  fact, 
one  senior-level  executive  complained,  "Those  people  are 
nuts!  They  live  in  their  own  little  world  and  rhapsodize 
to  each  other  about  bits,  bytes  and  MIPS."  trillions  of 
instructions  per  second]  (10i 24) 

The  future  user  does  not  care  about  all  that  technical  "mumbo- 
jumbo".  The  user  wants  a  system  that  helps  do  the  job  regardless 
of  what  it  technically  entails. 

Therefore,  the  head  of  the  organization  should  select  an  indi¬ 
vidual  who  understands  the  organization  from  the  users'  perspec¬ 
tive  and  who  also  has  the  training  or  interest  to  understand  the 
technical  jargon.  "Cultivating  the  ability  to  communicate  to  the 
non-DP  manager  in  his  own  language  is  one  of  the. . .guidelines  for 
success..."  (10|25).  The  person  in  charge  of  implementing  the  sys¬ 
tem  must  have  the  kind  of  personality  that  allows  him  to  communi¬ 
cate  readily  and  easily  with  the  users.  This  will  be  critical 
downstream  when  the  implementation  phase  begins. 

The  organization  head  has  two  very  important  decisions  to 
make  at  the  outset.  The  first  is  who  should  be  responsible  for 
implementing  the  system,  i.e.,  the  person  of  primary  responsibil¬ 
ity  -  the  implementer.  The  second  decision  is  where  that  indi¬ 
vidual  should  reside  in  the  organization.  Hopefully,  the  organi¬ 
zation  head  can  find  the  right  individual  within  the  organiza¬ 
tion,  but  it  may  be  necessary  to  bring  someone  in  from  outside. 


Going  outside  the  organisation  has  its  advantages  and  disad¬ 
vantages.  The  advantages  are  that  the  individual  found  might 
be  more  qualified*  and  they  have  a  fresh  perspective  coming  in, 
i.e.,  no  preconceived  biases.  The  disadvantage  is  that  they  do 
not  have  knowledge  of  the  internal  woncings  of  the  organization. 
Thus,  they  are  more  prone  to  making  mistakes  early  in  the  pro¬ 
cess,  and  the  learning  curve  required  to  become  familiar  with  the 
organization  may  delay  the  development  effort.  However,  it  is 
more  important  to  get  a  quality  system  than  to  get  it  quickly, 
so  an  extensive  effort  should  be  made  to  get  the  most  qualified 
person  no  matter  what  the  source. 

Once  the  individual  is  selected,  the  next  decision  is  where 
to  assign  this  implementer.  Since  the  individual  will  be  imple¬ 
menting  change  and  enacting  a  system  that  crosses  all  elements 
of  the  organization,  the  organization  head  should  place  him  on 
his  immediate  staff,  reporting  directly  to  him.  There  are 
several  reasons  for  doing  this.  The  fact  that  the  new  system 
will  change  the  way  the  organization  does  business  will  lead  to 
controversy.  People  resist  change.  The  implementer  will  be 
fighting  an  uphill  battle  if  he  does  not  have  the  strong  support 
of  the  head  of  the  organization.  Therefore,  it  must  be  clear  from 
the  outset  that  the  implementer  works  directly  for  the  organiza¬ 
tion  head,  has  the  boss*  total  support,  and  has  complete  autonomy 
to  cross  suborgan izational  lines.  This  also  gives  the  implementer 
quick  access  to  the  boss  should  any  resistance  at  lower  levels 


The  author  has  had  experience  in  this  area.  When  he  was  im¬ 
plementing  a  system  at  the  Air  Staff,  he  was  assigned  to  a  sub¬ 
element  of  the  overall  organization.  Although  the  author  tried 
constantly  to  treat  each  subelement  equally,  those  in  other  sub¬ 
elements  consistently  accused  him  of  showing  favoritism  to  the 
subelement  he  was  assigned  to.  He  also  met  resistance  from  mem¬ 
bers  of  other  subelements  because  he  was  not  viewed  as  having 
their  total  interests  in  mind.  Although  the  author  went  out  of 
his  way  by  compensating  in  favor  of  the  other  subelements,  the 
resistance  and  controversy  would  have  been  eliminated  if  he  had 
been  a  member  of  the  direct  staff  of  the  organization  head. 

Another  office  at  the  Air  Staff  experienced  similar  diffi¬ 
culty.  The  office  of  the  Air  Staff  Information  Management  Sys¬ 
tem  (ASIMS)  was  originally  organized  as  a  division  under  the 
Director  of  Administration.  The  ASIMS  office  was  responsible 
for  implementing  an  information  system  linking  together  the  total 
Air  Staff.  This  office  had  great  difficulty  getting  the  support 
it  needed  from  the  other  deputy  chiefs  of  staff.  It  became  so 
cumbersome  that  the  office  had  to  be  moved  directly  under  the 
Assistant  Vice  Chief  of  Staff  of  the  Air  Force,  the  individual 
who  heads  the  Air  Staff.  After  this  change  was  made,  the  ASIMS 


office  had  the  recognized  support  at  the  top  needed  to  make  it 
an  effective  organization.  The  other  deputy  chief  of  staff 
organizations  quickly  became  more  cooperative. 

At  Air  Command  and  Staff  College  (ACSC),  the  same  mistake  is 
being  made.  The  individual  assigned  responsibility  for  imple¬ 
menting  the  information  system  works  in  the  Directorate  of  Cur¬ 
riculum.  Although  the  ACSC  Commandant  strongly  supports  the 
system,  as  the  development  progresses  through  its  various  stages, 
the  implementer  will  experience  unnecessary  difficulty  if  he 
does  not  work  directly  for  the  Commandant.  Although  it  may  seem 
like  a  minor  thing  in  a  mature  organization,  many  problems  and 
barriers  can  be  overcome  if  the  organization  head  locates  the 
implementer  properly  within  the  organizational  structure. 


THE  INFORMATION  SYSTEM  TEAM 

Once  the  system  implementer  is  assigned,  he  needs  to  form 
the  information  system  team.  The  team  should  consist  of  a  rep¬ 
resentative  from  each  of  the  major  subelements  of  the  organization, 
e.g.,  each  of  the  directorates  of  ACSC.  Again,  care  must  be  ta¬ 
ken  in  selecting  the  team  members.  They  should  be  individuals 
who  understand  the  internal  workings  of  their  element  of  the 
organization,  who  support  change  that  improves  the  organization, 
and  who  are  willing  to  assist  the  implementer  and  the  members 
of  their  element  in  implementing  the  system. 

Ron  Mead,  a  human  factors  specialist  with  the  US  Office  of 
Personnel  Management ,.. .claimed  that  as  many  as  4o  percent 
of  all  functionally  sound  office  automation  systems  fail 
to  provide  the  expected  benefits  because  of  a  lack  of  coop¬ 
eration  from  users... Mead  said  users'  negative  attitudes 
can  often  be  partially  attributed  to  office  automation 
planning  teams.  These  teams  often  alienate  users  by  in¬ 
timidating  them  with  jargon,  he  explained,  or  by  ignoring 
them  altogether. 


To  overcome  user  resistance,  office  automation  teams  must 
improve  teamwork,  involve  users  in  the  decision-making  pro¬ 
cess  and  help  make  them  break  their  fears  about  automation. 
(6:82) 

Since  assignment  to  the  information  system  team  will  probably  be 
an  additional  duty,  other  factors  to  consider  when  selecting  mem¬ 
bers  are  the  restrictiveness  of  their  primary  duties,  the  amount 
of  time  remaining  on  their  assignment  to  the  organization,  and 
their  training,  experience,  and  interests.  The  individuals  se¬ 
lected  must  be  motivated  to  participate  aggressively  on  the  team. 

Team  organization  should  be  handled  on  two  levels... The 
broad  decisions  can  be  made  by  a  task  force  representing 
every  segment  of  the  organization  likely  to  be  affected 


by  office  automation.  More  specific  areas  are  dealt 
with  by  small  committees.  In  addition,  the  team  can  en¬ 
courage  and  help  form  user  groups  throughout  the  organi¬ 
zation  to  ease  the  transition.  (7:82-85) 

After  the  team  is  formed,  the  next  step  is  to  determine  existing 
capabilities  and  possible  action  that  has  already  been  completed. 


WHERE  ARE  WE  NOW? 

The  first  action  to  be  taken  by  the  implementer  and  the  infon 
mation  system  team  is  determining  what  has  already  been  done. 

Few  Air  Force  organizations  lack  at  least  some  type  of  automated 
information  support.  Most  organizations  have  either  word 
processing  equipment,  microcomputers,  or  a  remote  terminal  that 
accesses  a  larger  computer.  Since  these  devices  and  capabili¬ 
ties  will  need  to  be  incorporated  into  the  total  system,  the 
team  needs  to  start  out  understanding  what  these  devices  are, 
what  they  do,  and  what  requirements  drove  their  procurement  and 
installation.  The  first  step,  then,  is  to  conduct  a  survey  of 
the  numbers  and  types  of  devices  already  installed  by  organiza¬ 
tional  subelement. 

The  next  step  in  determining  where  we  are  now  is  to  gather 
organizational  information.  The  author  has  found  it  helpful  to 
obtain  a  mission  statement  for  each  subelement  so  all  the  team 
members  understand  the  functions  of  each  of  the  elements. 

Another  useful  tool  is  an  organizational  chart  with  authorized 
personnel  numbers  by  grade  for  each  subelement.  Since  the  infor¬ 
mation  system  will  include  devices  to  be  used  by  these  personnel, 
the  number  required  depends  on  authorized  manning  and  where 
these  personnel  are  located.  Therefore,  a  floor  plan  of  the 
buildings  assigned  to  the  organization  containing  a  synopsis  of 
which  elements  are  housed  where  will  be  needed. 

In  both  systems  that  the  author  worked  on,  an  Air  Force _ 
Regulation  4-2  word  processing  survey  had  been  conducted  within 
the  organizations,  and  word  processing  equipment  was  installed 
or  ordered.  The  word  processing  survey  requires  that  typists 
record  the  number  of  lines  of  information  typed  during  a  given 
period,  indicating  the  source  and  format  output  for  the  infor¬ 
mation  as  well  as  its  destination.  The  author  has  found  that 
this  information  is  quite  helpful  to  the  information  system  team 
in  understanding  the  information  flow  within  the  organization. 

If  this  has  not  been  done,  the  team  needs  to  conduct  an  AFR  4-2 
or  similar  survey  to  determine  this  information.  After  this 
information  is  gathered,  the  team  needs  to  step  back  and  look  at 
their  organization  from  a  bigger  perspective. 


The  information  system  team  must  recognize  that  their 
organization  does  not  function  in  total  isolation  of  other 
organizations.  Therefore,  one  of  the  initial  taskings  of  the 
team  is  to  determine  whether  their  information  system  needs  to 
interface  with  or  be  a  part  of  another  information  system.  And, 
if  it  does,  have  arrangements  been  made  to  maximize  cross-flow 
of  information  so  the  parts  can  be  integrated  at  a  later  date? 

At  the  Air  Staff,  the  author  was  implementing  a  system  for 
one  of  the  deputy  chiefs  of  staff.  He  recognized  that  most  of 
the  information  generated  and  received  in  the  DCS  came  from 
within.  However,  there  was  a  requirement  to  be  able  to  inter¬ 
face  with  the  other  DOS's  information  systems  as  well  as  those 
at  the  major  air  command  level.  Therefore,  as  implementer  of 
the  DOS's  information  system,  he  also  needed  to  ensure  that  his 
system  would  fit  with  the  others.  To  do  this,  he  became  a  member 
of  the  Air  Staff  Information  Management  System  team  and  used 
that  forum  to  insure  that  his  system  was  going  to  fit  within  the 
overall  Air  Staff  system. 

At  Air  Command  and  Staff  College,  the  same  approach  must 
be  followed.  The  ACSC  information  system  team  must  insure  that 
their  system  fits  into  any  Air  University  plans  as  well  as  plans 
by  the  Air  Force  Data  Systems  Design  Center  to  provide  automated 
support  for  Air  University.  Additionally,  as  the  Air  Staff 
develops  the  "Air  Force  Information  Systems  Architecture"  (11*7) 
and  the  necessary  standards  to  support  that  architecture,  the 
ACSC  team  must  insure  that  their  plans  will  generate  a  system 
that  meets  the  standards  and  fits  the  architecture.  If  this 
information  is  not  available,  ACSC  has  two  options. 

The  first  option  is  to  wait  for  the  architecture  and  stan¬ 
dards  to  be  established.  This  is  probably  not  a  good  option 
for  it  will  delay  the  ACSC  system  for  an  undetermined  period  of 
time.  The  second  option  is  to  implement  the  ACSC  system  with¬ 
out  this  information,  but  incorporate  as  much  f lexibility. as 
possible  into  the  system  so  that  the  difficulty  and  cost  involved 
in  meeting  the  standards  and  fitting  the  architecture  at  a  later 
date  are  minimized.  An  example  of  a  standard  that  will  be  forth¬ 
coming  is  the  Department  of  Defense's  Ada  programming  language. 

Because  each  service  branch  maintains  hundreds  of  dif¬ 
ferent  types  of  computers ,  each  also  must  cope  with  a 
great  variety  of  languages . 

To  resolve  this  confusion,  DOD  decided  to  adopt  one  lan¬ 
guage  that  would  enable  the  equipment  of  all  four  branches 
to  communicate.  More  important,  a  single  language  would 
make  it  easier  to  manage  the  millions  of  lines  of  program 


code  that  each  service  uses  to  run  its  hardware. 


The  resulti  a  very  powerful,  high-level  language  that 
avoids  the  pitfalls  that  make  existing  languages  hard 
to  manage  and  maintain.  (6:12?) 

ACSC  does  not  want  to  wait  for  this  language  development  to  meet 
its  applications  nor  does  it  want  to  pay  the  price  in  today's 
market  to  have  the  code  written  in  Ada  to  meet  its  needs.  What 
ACSC  does  need  to  do  is  be  aware  of  this  future  standard  and 
design  into  its  information  system  the  flexibility  to  incor¬ 
porate  Ada  at  a  later  date. 

Now  that  the  information  system  team  is  formed  and  chaired  by 
the  system  implementer  and  it  has  gathered  the  appropriate 
background  information  and  considered  the  outside  factors,  it 
is  time  to  start  the  planning  process.  The  first  step  of  the 
planning  process  is  determining  what  the  requirements  are. 
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Chapter  Three 


REQUIREMENTS 


DETERMINING  THE  REQUIREMENT 

Determining  the  requirement  is  probably  the  most  difficult 
task  of  implementing  automated  information  systems.  It  does  not 
appear  that  it  should  be  that  difficult.  V.'e  now  have  an  infor¬ 
mation  system  team.  Let  its  members  go  ask  the  individuals 
assigned  to  the  organization  what  they  need  in  the  area  of  infor¬ 
mation  system  support.  They  will  probably  get  a  lot  of  blank 
stares. 

As  the. . .terminal-based  systems  evolve,  they  will 
become  a  natural  part  of  the  life  of  a  manager  or 
professional  in  the  same  way  that  they  are  now  a 
part  of  the  operational  life  of  an  enterprise.  (903) 

People  have  trouble  explaining  what  they  need  when  the  system 
is  going  to  change  the  way  they  do  business.  It  is  hard  to 
express  a  requirement  for  something  when  one  does  not  understand 
what  that  something  is.  The  information  system  team  is  therefore 
confronted  with  a  problem.  How  do  they  develop  the  requirement? 

The  most  logical  thing  to  do  is  educate  the  future  users  on 
what  capabilities  are  available  in  the  market  place  and  then  let 
them  decide  if  they  need  those  capabilities  and,  if  so,  how  they 
would  use  them.  The  author  used  demonstrations  by  commercial 
vendors  of  their  products  and  attendance  at  trade  shows  to 
educate  the  prospective  users  on  the  capabilities  of  available 
commercial  devices.  He  followed  this  up  with  a  questionaire 
asking  what  features  would  be  required  and/or  desired  in  an 
information  system  and  how  they  would  be  used  by  the  organization. 

Most  system  users  are  driven  by  a  motivating  application, 
a  requirement  that  acts  as  the  proximate  cause  for 
acquiring  and  using  a  system.  While  they  may  have 
use  for  additional  capabilities  and  may  in  fact  use 
them  once  the  system  is  deployed,  the  motivating 
application  dominates  all  other  considerations.  The 
user  will  want  the  very  best  system  for  this  applica¬ 
tion  that  he  can  get.  Other  considerations,  including 
the  nature  and  accessibility  of  secondary  applications, 
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pale  by  comparison  (8i42). 

Therefore,  the  information  system  team  must  determine  what 
primary  application  the  users  require  first.  The  initial  require¬ 
ment  of  the  system  is  the  combination  of  hardware  and  software 
that  provides  that  application.  Then,  the  team  must  decide  on 
the  second  most  important  application,  then  the  third,  then  the 
fourth,  etc.  This  information  provides  a  good  starting  point  for 
the  development  of  the  information  system  plan. 


AN  EVOLUTIONARY  PROCESS 

Before  the  team  presses  on  to  develop  the  plan,  they  need  to 
consider  a  couple  of  other  factors.  The  most  important  one  is 
the  availability  of  money  to  fund  the  system.  The  author's 
experience  is  that  money  provides  an  immediate  restriction  on 
how  the  plan  is  developed.  In  both  cases  that  the  author  has 
been  involved  with,  there  was  no  initial  money  programmed  or 
available  to  fund  the  system.  It  was  possible  to  reprogram 
some  money  or  to  use  funds  like  productivity  improvement  funds 
to  start  the  system.  However,  a  plan  without  the  supporting 
funds  to  execute  it  has  little  value.  Therefore,  as  the  plan 
is  developed,  it  must  be  done  from  the  realistic  perspective 
that  funds  are  going  to  be  a  limiting  factor  in  the  early  stages 
and  maybe  throughout  the  entire  system  implementation. 

A  second  factor  for  the  team  to  consider  is  that  technology 
is  advancing  so  rapidly  in  the  area  of  information  systems  that 
technological  obsolescence  must  be  a  concern.  The  plan  should 
call  for  an  evolutionary  development  of  the  system  rather  than 
a  revolutionary  change.  The  plan  should  allow  for  the  necessary 
flexibility  to  take  advantage  of  new  technology  as  it  becomes 
available.  This  means  that  the  total  system  should  be  modular 
so  that  new  enhancements  can  be  added  and  outdated  elements 
deleted  without  significantly  degrading  the  performance  of  the 
system.  Also,  individual  elements  should  be  procured  with  op¬ 
tions  for  upgrading  or  expanding  their  capabilities  at  a  later 
date. 


Another  reason  for  the  evolutionary  approach  is  it  allows 
the  organization  to  gradually  transition  into  the  new  way  of 
conducting  business  instead  of  making  an  abrupt  change  that  dis¬ 
rupts  the  organization's  mission  effectiveness.  When  dramati¬ 
cally  changing  the  work  environment,  it  is  smart  to  ease  into  the 
change  gradually  so  that  individuals  have  a  chance  to  adjust  to 
the  new  conditions.  In  addition,  the  training  required  for  using 
the  new  technology  will  be  quite  extensive.  Productivity  will  be 
degraded  less  if  the  training  can  be  spread  over  a  longer  period, 
thereby  involving  less  people  at  any  one  time. 


•  < 
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Combining  the  requirement  to  meet  specific  applications,  the 
probable  restriction  on  funding,  the  rapidly  changing  technology, 
and  the  organizational  transition  that  will  occur,  an  evolution¬ 
ary  process  of  requirements  determination  and  systems  development 
becomes  a  sound  management  approach.  In  other  words,  the  infor¬ 
mation  system  team  should  not  try  to  lock  in  the  requirements  for 
the  total  system.  They  should  develop  the  requirements  based  on 
the  applications  needed  today,  but  they  should  remain  flexible 
knowing  that  the  requirements  will  change.  A  logical  approach 
is  to  develop  specific  requirements  for  priority  applications 
with  fairly  general  requirements  for  applications  that  will  be 
developed  later. 

Armed  with  the  requirements,  the  information  system  team 
should  be  ready  to  begin  preparation  of  the  system  plan. 


Chapter  Four 


THE  PLAN 


LONG  RANGE  GOALS 

The  information  system  team  should  begin  the  development  of 
the  organization's  information  system  plan  by  establishing  some 
long  range  goals.  For  the  purpose  of  information  systems  with 
their  rapidly  changing  technology,  these  goals  should  be  direct¬ 
ed  towards,  but  not  limited  to,  five  years  from  the  plan  incep¬ 
tion.  They  should  include  all  the  applications  identified  during 
the  requirements  determination  process.  These  goals  should  pro¬ 
ject  where  the  information  system  team  would  have  the  organization 
evolve  to  in  the  foreseeable  future,  eclipsing,  if  necessary, 
both  monetary  and  technological  limitations. 

At  the  Air  Staff,  the  author  developed  long  range  goals  that 
included  both  quantities  of  devices  and  capabilities  desired. 

The  goal  was  to  have  one  work  station  for  at  least  every  two 
authorized  personnel  at  the  five-year  point.  Long  range  capabil¬ 
ity  goals  included  on-line  storage  and  retrieval  of  all  unclassi¬ 
fied  information  used  by  the  DCS  and  electronic  coordination  of 
documents  throughout  the  organization.  There  were  other  long 
range  goals  that  were  included  in  the  plan  but  were  not  defined 
as  five-year  goals  because  they  depended  on  technological  devel¬ 
opments  or  actions  by  outside  agencies.  These  included  such 
things  as  storage  and  retrieval  of  classified  and  unclassified 
information  on  the  same  network  -  a  capability  that  required 
development  of  new  technology  to  meet  the  security  requirements, 
and  electronic  coordination  of  information  across  the  total  Air 
Staff  -  a  capability  that  the  ASIMS  office  had  to  develop.  These 
goals  were  included  in  the  plan  to  insure  that  the  DCS  system  re¬ 
mained  flexible  enough  to  incorporate  these  capabilities  when  they 
became  available. 


THE  ARCHITECTURE 

Once  the  information  system  team  has  developed  their  long 
range  goals,  they  must  construct  an  architecture  on  paper  that 
displays  how  they  view  the  individual  pieces  fitting  together. 
This  architecture  should  be  designed  from  both  the  hardware  and 
networking  standpoint  and  the  organization's  information  flow. 
The  architecture  is  a  graphic  projection  of  how  the  various  com 


puters,  peripherals,  networks,  and  applications  would  be  config¬ 
ured  to  fulfill  long  range  goals. 


We  will  get  to  the  office  of  the  future  by  installing  par¬ 
ticular  solutions  to  particular  problems,  until  we  wake 
up  one  day  and  find  ourselves  with  a  new  working  envi¬ 
ronment.  System  planners  must  design  their  ultimate 
office  architectures,  but  these  architectures  will  be 
implemented  in  an  indirect  fashion.  The  key  to  success 
is  ensuring  that  individual  solutions  to  immediate  prob¬ 
lems  adhere  to  an  overall  architectural  vision,  so  that 
the  end  product  is  consistent,  rather  than  fragmented 
(8:46). 

The  architecture  serves  as  a  roadmap  to  assist  the  team  in 
insuring  that  each  element  of  the  system  fits  the  total.  At  the 
Air  Staff,  the  author’s  architecture  included  word  processing 
equipment,  personal  computers,  mini-computers,  mainframes,  ter¬ 
minals,  printers,  optical  character  recognition  devices,  elec¬ 
tronic  typewriters,  automated  storage  and  retrieval  systems, 
local  area  networks,  automated  phone  systems,  teleconferencing 
systems,  etc.  Although  some  of  these  items  and  the  applications 
they  were  to  address  were  not  near  term  goals,  they  were  included 
in  the  architectural  design  to  insure  that  each  part  would  fit 
when  finally  implemented. 


INTERIM  PHASES 

After  developing  the  long  range  goals  and  constructing  the 
architectural  roadmap,  the  team  is  ready  to  decide  which  require¬ 
ments  they  wish  to  fulfill  and  when.  Since  the  information  sys¬ 
tem  is  being  developed  in  an  evolutionary  manner,  the  team  must 
decide  how  it  wants  to  phase  the  development  process  based  on  a 
logical  review  of  money  available,  the  urgency  of  the  various  re¬ 
quirements,  and  an  intelligent  approach  for  constructing  the  sys¬ 
tem. 


At  the  Air  Staff,  the  team  decided  that  providing  automated 
support  to  the  administrative  support  personnel  who  spent  more 
than  half  of  their  time  typing  (roughly  6 0%  of  the  secretaries) 
was  the  most  urgent  requirement.  So,  word  processing  devices 
were  procured  for  them  during  Phase  I .  Phase  I  also  included 
procurement  of  a  sampling  of  minimum-capable  electronic  type¬ 
writers  for  those  administrative  support  personnel  who  did  not 
type  half  of  the  time.  Professional  staff  work  stations  were 
also  procured  for  one  division  (roughly  five  percent  of  the 
professional  work  force).  Phase  I  got  the. system  started  within 
the  funding  limitations,  met  the  most  critical  need,  and  allowed 
for  prototyping  of  some  of  the  automated  capabilities  to  deter¬ 
mine  if  the  quantities  and  capabilities  were  appropriate  to  meet 
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the  requirements.  Built  into  the  plan  were  checkpoints  between 
phases  to  allow  for  review  before  proceeding  to  the  next  phase. 


CHECKPOINTS 


Checkpoints  are  pre-planned  pauses  where  the  information  sys¬ 
tem  team  stops  to  evaluate  the  effectiveness  of  the  systematic 
evolutionary  process  up  to  that  point  before  a  decision  is  made 
to  continue  on  with  the  phase.  These  evaluations  can  be  done  by 
the  team  or  an  outside  agency,  whichever  is  deemed  more  appro¬ 
priate.  However,  these  decisions  should  be  made  up  front  and  in¬ 
corporated  into  the  plan. 

At  the  Air  Staff,  the  team  conducted  the  evaluation  after 
Phase  I  and  found  that  the  electronic  typewriters  with  minimum 
capability  were  not  adequate  to  meet  the  needs  of  the  secretaries 
they  were  designed  for.  Thus,  the  team  decided  to  upgrade  these 
devices  to  enhance  their  features  and  procure  similarly  enhanced 
devices  for  the  remainder  of  the  secretaries  during  Phase  II. 

The  sampling  of  the  professional  work  stations  proved  their 
adequacy,  and  they  were  likewise  procured  for  the  rest  of  the 
professional  staff.  The  team  required  an  outside  agency  to  con¬ 
duct  the  evaluation  after  Phase  II  to  get  an  unbiased  evaluation 
of  the  system  development  up  to  that  point  and  to  approve  the  im¬ 
plementation  of  Phase  III. 


GETTING  APPROVAL 

After  the  information  system  team  completes  the  plan  with  its 
long  range  goals,  its  interim  phases,  and  an  explanation  of  the 
checkpoints  and  who  will  do  the  evaluations,  it  is  time  to  get 
approval  for  the  plan  from  the  organization  head  and  the  chiefs 
of  the  various  organizational  subelements.  The  best  approach 
for  accomplishing  this  is  to  give  these  individuals  a  copy  of 
the  plan  in  advance  and  then  have  all  in  attendance  at  a  brief¬ 
ing  of  the  plan  to  the  organization  head.  This  forum  allows  for 
open  discussion  of  the  plan  and  reiterates  the  boss'  support 
for  the  implementation  of  the  system.  The  system  implementer 
should  have  each  team  member  coordinate  the  plan  with  their 
respective  subelement  chief  and  resolve  any  problems  prior  to  the 
meeting.  The  success  of  the  system  implementation  depends  on  a 
consensus  that  the  plan  is  sound  and  that  all  elements  of  the  or¬ 
ganization  agree  to  support  it.  After  this  is  accomplished,  the 
team  is  ready  to  begin  the  implementation  process. 


Chapter  Five 


IMPLEMENTATION 


MAKING  IT  HAPPEN 

The  implementation  process  begins  by  implementing  the  first 
phase  of  the  information  system  team's  plan.  Now  is  the  time 
when  the  implementer  feels  like  he  must  become  a  technical  expert, 
a  supply  officer,  a  contracting  officer,  and  a  budgeting  officer 
all  rolled  into  one.  To  accomplish  this  monumental  task,  he  must 
seek  the  support  of  each  of  these  disciplines  and  comply  with 
all  their  regulations. 

First,  he  must  get  approval  from  the  appropriate  technical 
support  function.  If  he  is  procuring  word  processing  equipment, 
he  must  comply  with  the  4-series  regulations.  If  it  is  communi¬ 
cations  equipment,  then  he  uses  the  100-series  regulations.  If 
it  is  automated  data  processing  equipment,  he  must  comply  with 
the  300-series  regulations.  In  the  future,  hopefully,  the  700- 
series  regulations  will  consolidate  the  three  other  technical 
series  into  one  series.  However,  today,  the  implementer  of  an 
automated  information  system  must  comply  with  each  one  of  these 
since  the  system  probably  includes  elements  of  all  of  them. 

The  implementer  should  meet  with  the  appropriate  technical 
support  personnel  and  draft  a  technical  specification  of  the  cap¬ 
abilities  needed  in  the  items  to  be  procured.  The  specification 
is  used  in  the  documentation  to  obtain  approval  from  the  technical 
support  function  and  also  in  the  scope  of  work  used  by  the  con¬ 
tracting  officer.  The  technical  expert  should  provide  the  word¬ 
ing  necessary  to  communicate  the  capabilities  required  to  the  po¬ 
tential  vendor  in  the  technical  jargon  used  by  that  industry. 

The  technical  specification  must  also  include  training  (initial 
and  follow-on),  electrical  requirements,  environmental  factors 
(temperature  and  humidity),  peripheral  equipment  needed,  etc. 

In  addition,  the  technical  expert  should  assist  the  implementer 
in  preparing  the  other  documentation  required  by  the  technical 
regulations  to  obtain  approval  to  proceed  with  the  procurement . 
Once  the  technical  approval  is  obtained,  the  implementer  proceeds 
to  the  next  support  function. 

The  implementer  then  takes  the  technical  information  with  the 
appropriate  supply  requisition  to  the  supply  officer.  The  supply 


officer  processes  the  requisition  and  advises  on  initial  supplies 
needed  to  go  with  the  procurement  as  well  as  establishing  stock 
levels  to  meet  recurring  demands.  The  supply  officer  and  techni¬ 
cal  expert  should  advise  the  implementer  on  an  appropriate  main¬ 
tenance  plan  to  include  with  the  requisition. 

Next,  the  implementer  goes  to  the  budgeting  officer  to  get 
money  appropriated  to  procure  the  item.  The  lease  versus  buy 
option  is  discussed  here  and  many  times  depends  on  the  funds  the 
budget  officer  has  available.  Since  procurement  (buy)  money  is 
normally  at  a  premium,  the  decision  will  probably  be  made  to  lease 
with  options  to  buy.  After  the  supply  and  budget  officers  have 
approved  the  requisition,  it  goes  to  the  contracting  officer.  At 
this  level,  a  whole  different  set  of  guidance  comes  into  play. 

To  get  approval  to  buy  an  information  system  element  under  the 
new  700-series  regulations  will  require  computation  of  life-cycle 
costing  of  several  alternatives.  The  implementer  would  natural¬ 
ly  assume  after  completing  this  analysis  that  the  least  cost 
alternative  that  meets  his  needs  would  be  the  one  procured.  Well, 
the  contracting  officer  applies  his  regulations  now,  and  they  may 
force  a  competitive  procurement,  a  small  business  set  aside,  or 
some  other  method  of  acquisition  that  obliterates  the  life-cycle 
costing  analysis. 

The  bottom  line  is  that  to  implement  an  information  system  in 
the  Air  Force  today  requires  the  implementer  to  comply  with  at 
least  six  or  seven  different  series  of  regulations.  Each  series 
is  very  complicated  and  requires  a  formal  approval  process  before 
the  implementer  can  proceed  to  the  next  series.  This  forces  the 
implementer  to  become  knowledgeable  in  all  these  areas  and  to  mon¬ 
itor  a  myriad  of  documents  daily.  A  successful  implementer  must 
garner  the  support  of  each  of  the  functional  experts  very  early 
in  the  implementation  process  if  he  wants  to  avoid  frustration, 
embarrassment,  and  system  development  delays  later  on. 


HAND  HOLDING 

Assuming  that  the  implementer  has  closed  the  procurement 
loop  and  the  devices  are  delivered,  now  comes  one  of  the  most 
critical  times  for  the  organization  and  the  implementation  of  its 
automated  information  system.  The  vendor  who  is  awarded  the  con¬ 
tract  should  install  the  system  and  provide  initial  training. 

That  implies  that  the  implementer ' s  job  is  through.  Nothing 
could  be  farther  from  the  truth.  The  implementer  has  to  schedule 
delivery  and  training.  This  normally  entails  insuring  that  the 
organization  is  ready  to  receive  the  equipment  and  that  the 
environment,  electrical  outlets,  and  furniture  are  positioned  to 
install  the  devices.  The  implementer  also  has  to  arrange  a  room 
for  training  and  insure  that  the  appropriate  personnel  are  allowed 
to  attend  the  training.  Many  times,  training  is  accomplished 


using  the  devices  that  were  just  delivered,  so  they  have  to  be 
put  in  a  training  room  first  and  then  moved  to  their  operational 
environment.  Another  option  is  for  the  vendor  to  conduct  train¬ 
ing  at  the  vendor  location.  This  means  that  organizational  per¬ 
sonnel  must  report  to  the  vendor's  location.  This  is  not  always 
a  desirable  arrangement.  Therefore,  it  is  best  to  cover  the 
training  location  and  what  devices  will  be  used  for  training  in 
the  technical  specifications  and  the  ensuing  contract. 

After  initial  training,  the  vendor  is  usually  required  to 
provide  follow-on  assistance  to  the  trainees.  The  vendors 
use  what  they  call  marketing  support  representatives  for  this 
purpose.  The  author  recommends  that  the  contract  specify  that 
the  marketing  support  representative  spend  many  hours  within 
the  user  organization  during  the  first  few  weeks  after  initial 
training.  This  is  the  period  of  the  peak  of  the  learning  curve, 
and  the  trainees  will  require  much  hand  holding  during  this 
period.  When  the  author  was  going  through  this  phase  at  the  Air 
Staff,  he  dedicated  an  Air  Force  resource  to  be  the  expert  user 
of  the  new  device  and  to  be  available  to  answer  any  questions 
when  the  marketing  support  representative  was  not  around.  This 
is  the  period  of  greatest  frustration  for  the  user.  They  are 
using  an  unfamiliar  system  that  is  forcing  them  to  change  the  way 
they  normally  work.  It  is  critical  that  this  period  be  made  as 
easy  as  possible  for  the  user. 


GETTING  FEEDBACK 

During  the  early  stages  of  the  implementation  phase  of  the 
information  system,  the  implementer  must  not  only  hold  the  users' 
hands,  but  he  must  also  get  as  much  feedback  as  possible  from  the 
users  and  the  organizational  chiefs.  The  author  found  two  effec¬ 
tive  means  for  getting  feedback.  The  first  was  to  hold  bi-weekly 
users'  meetings  during  the  first  few  months  after  installation 
of  a  new  device.  These  meetings  provided  an  opportunity  for  users 
to  share  good  ideas  and  difficulties  they  were  having.  The  dis¬ 
cussion  at  these  meetings  provided  the  feedback  needed  by  the  im¬ 
plementer  to  insure  the  devices  were  fulfilling  their  stated 
purpose.  The  second  means  used  by  the  author  was  to  make  weekly 
trips  to  each  of  the  duty  sections  where  the  devices  were,  an¬ 
swering  questions  and  asking  the  chiefs  and  users  what  successes 
or  failures  they  were  having  as  a  result  of  the  information  sys¬ 
tem  elements. 

Feedback  obtained  in  this  fashion  provides^  sound  basis  on 
which  to  evaluate  the  effectiveness  of  the  devices  and  the  system 
to  use  at  checkpoints  in  deciding  whether  to  continue  with  the 
next  phase  of  the  plan.  The  implementer  should  document  diffi¬ 
culties  and  bring  them  up  to  the  information  system  team  for 
resolution.  After  each  phase  of  the  implementation  plan  is  com¬ 
pleted  and  evaluated,  the  implementer  should  press  on  and  initiate 
the  next  phase. 
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FLEXIBILITY  IS  THE  KEY 

The  evolutionary  process  described  in  Chapter  Three  is 
designed  to  maintain  flexibility  throughout  the  system 
implementation.  Therefore,  the  biggest  mistake  an  implementer 
could  make  would  be  to  stick  rigidly  to  the  initial  plan.  Each 
subsequent  phase  should  be  modified  to  take  advantage  of  the 
lessons  learned  during  the  implementation  of  the  previous  phase 
and  its  subsequent  evaluation.  The  implementer  should  also 
remain  cognizant  of  advances  in  technology  and  changes  in  the 
organization  environment. 

The  strategy  is  both  organizational  and  technological  in 
nature.  These  two  driving  forces  must  be  synchronous  for 
optimum  benefits  and  flexible  enough  to  respond  to  a  real¬ 
istic  spectrum  of  business  possibilities.  A  "do  it,  fix 
it,  try  it"  attitude  is  ingrained  in  this  strategy  (12s62). 


Industry  has  learned  this  lesson.  The  Air  Force  can  likewise 
implement  successful  information  systems  if  it  is  willing  to 
transition  from  a  revolutionary  process  to  an  evolutionary  one. 
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Chapter  Six 


CONCLUSIONS 


STEP-BY-STEP  PROCEDURES 

This  paper  has  outlined  the  step-by-step  procedures  that 
^iouH  be  used  by  any  organization  in  implementing  automated 
information  systems.  Tne  first  step  must  be  made  by  the  head 
of  the  organization  when  he  decides  who  the  individual  should 
be  that  implements  the  system  and  where  that  individual  should 
reside  in  the  organization.  Once  the  implementer  is  appointed, 
he  must  organize  the  information  systems  team.  The  team  then 
gathers  information  on  existing  capabilities  and  additional 
requirements.  This  information  is  used  to  develop  the  system 
plan  which  must  be  approved  by  the  organization  head  before  the 
full-scale  phased  implementation  can  begin.  This  procedure 
should  result  in  the  successful  implementation  of  an  automated 
information  system. 


RECOMMENDATIONS 

The  new  Assistant  Chief  of  Staff  for  Information  System  at 
the  Air  Staff,  Major  General  Gerald  L.  Prather,  has  the  unenviable 
task  of  providing  new  policy  to  govern  Air  Force  execution  of 
information  systems  implementation  in  the  1980' s  environment. 

This  requires  a  shift  from  centrally  oriented  infor¬ 
mation  services,  however,  to  more  supportive  decen¬ 
tralized  systems  responsibilities,  and  with  it,  the 
risks  of  "future  shock"  mishaps  and  degradation  of 
internal  controls.  A  controlled  outward  migration 
of  systems  resources  and  responsibilities  is  necessary, 
centered  around  an  explicit  systems  strategy  that 
assures  cost-effective  utilization  and  conscious 
risk  management  (12:62). 

To  assist  the  using  community  during  this  evolving  period, 
the  Air  Staff  should  develop  a  methodology  that  assists  the  user 
in  determining  their  applications  requirements  in  a  relatively 
simple  fashion.  General  Prather  stated,  "We’re  pursuing  possible 
alternatives  that  will  allow  us  to  streamline  and  standardize 
the  requirements  definition  process  and  speed  up  the  fielding  of 


vital  information  systems."  (10i?)  This  statement  indicates 
the  goal.  The  Air  Staff  should  task  Air  Force  Systems  Command 
to  use  their  experiences  and  those  of  industry  to  develop  this 
methodology. 

The  second  recommendation  is  to  insure  that  the  new  700-series 
regulations  streamline  the  approval  and  procurement  process.  These 
regulations  must  consolidate  the  procedures  currently  outlined  in 
the  4-,  100- ,  and  300-series  regulations  into  one  simple  approval 
process.  They  must  also  consider  the  supply,  budgeting,  and  pro¬ 
curement  regulations  and  align  the  documents  required  for  techni¬ 
cal  approval  with  the  documents  required  for  procurement.  Users 
should  be  allowed  to  complete  one  type  of  document  to  accomplish 
the  total  process. 

The  third  recommendation  for  the  Air  Staff  is  to  decentralize 
the  controls  on  information  system  elements.  Industry  has  recog¬ 
nized  that  their  data  processing  departments  are  not  going  to  con¬ 
trol  the  micro-technology  available  to  users  today.  The  Air  Force 
needs  to  recognize  this  fact  and  provide  intelligent  guidance  to 
users  instead  of  tight  controls. 

The  fourth  recommendation  is  to  develop  a  handbook  or  pam¬ 
phlet  to  guide  users  in  the  procedures  to  follow  in  procuring  sys¬ 
tem  elements.  The  handbook  could  include  the  steps  the  author  has 
outlined  in  the  appendix  to  this  paper.  It  should  also  alert  the 
user  to  other  factors  to  consider  as  well  as  potential  pitfalls 
that  might  be  encountered.  The  user  community  needs  something  that 
explains  how  to  go  about  implementing  an  information  system. 

The  fifth  and  final  recommendation  is  to  consider  relocating 
data  automaters  in  the  functional  areas  next  to  the  users.  As 
the  new  technology  is  incorporated  into  the  user  environment, 
more  applications  will  be  utilized  on  smaller  systems.  To  maxi¬ 
mize  the  benefit  from  the  information  system  technology,  compu¬ 
ter  programmers  will  be  needed  at  the  user  level  instead  of  in 
central  agencies.  An  initial  step  to  prototype  this  approach  with¬ 
in  an  organization  would  prove  the  advantages  and  disadvantages. 

The  Air  Force  has  taken  the  correct  step  in  forming  the 
Assistant  Chief  of  Staff  for  Information  Systems  at  the  Air  Staff. 
Now,  this  organization  must  exert  some  creative  leadership  so 
that  the  rest  of  the  Air  Force  can  benefit  from  the  information 
systems  approach.  The  gains  can  be  tremendous  if  old  ways  can  be 
forgotten,  and  new,  logical  means  are  found  to  streamline  the  im¬ 
plementation  and  management  of  this  evolving  environment. 
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APPENDIX 


PROCEDURES  FOR  IMPLEMENTING  INFORMATION  SYSTEMS 


1.  Getting  Started 

a.  Appoint  system  implementer. 

b.  Locate  implementer  in  organization. 

c.  Establish  information  system  team. 

d.  Survey  existing  capabilities  -  automated  devices  on-hand 
or  on-order. 

e.  Obtain  organizational  background  information  -  missions, 
manpower,  facilities,  and  related  information  system  documents. 

f.  Be  aware  of  other  information  systems  you  may  need  to 
interface  with. 

2 .  Requirements 

a.  Determine  applications  required. 

b.  Prioritize  these  applications. 

3.  The  Plan 

a.  Develop  long  range  goals. 

b.  Design  the  architecture. 

c.  Decide  on  the  interim  phases. 

d.  Pre-plan  checkpoints  and  decide  who  will  evaluate  at  each 
point . 

e.  Brief  plan  to  obtain  approval. 

4.  Implementation 

a.  Prepare  appropriate  documents  for  procurement. 

b.  Obtain  technical  support  function  approval. 

c.  Obtain  funding. 

d.  Requisition  through  supply. 

e.  Procure  through  the  contracting  office. 

f.  Monitor  installation  and  training. 

g.  Provide  assistance  to  users. 

h.  Get  feedback. 

i.  Evaluate  effectiveness  of  implemented  phases. 

j.  Repeat  implementation  procedures  for  next  phase. 
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